home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7183 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.4 KB  |  40 lines
  1. Newsgroups: comp.lang.c++
  2. Path: netcom.com!rbarris
  3. From: rbarris@netcom.com (Robert Barris)
  4. Subject: [STL] Safety of STL in a co-operative thread world?
  5. Message-ID: <rbarrisDn5J01.Ltz@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. Date: Thu, 22 Feb 1996 00:36:00 GMT
  8. Sender: rbarris@netcom11.netcom.com
  9.  
  10.  
  11. I have read some comments to the effect of 
  12.  
  13. "STL is not thread safe."
  14.  
  15. due to its use of static globals etc etc (which I have not checked out 
  16. for myslef, I took those comments at face value).
  17.  
  18. My question:
  19.  
  20. In a "co-operative" thread environment, such as that provided by several 
  21. third party DOS/Win3 libraries, or MacOS 7.5's Thread Manager whereby 
  22. thread switching only takes place in response to explicit "yield" 
  23. statements, is it likely that STL will work OK? That is to say, in the 
  24. absence of thread pre-emption.
  25.  
  26. Assume that yielding is not allowed inside any single STL primitive (ie, 
  27. no changes to the STL source). Further assume that threads explicitly 
  28. avoid operating on the same containers in overlapping time frames (I do 
  29. not expect STL to magically turn into a re-entrant multiuser database)...
  30.  
  31. I might be able to understand the situation better if I knew exactly what 
  32. the alleged static globals were, and what their purposes are.
  33.  
  34. Rob Barris
  35. Quicksilver Software Inc.
  36. rbarris@quicksilver.com / http://www.quicksilver.com/~rbarris/
  37. * Opinions expressed not necessarily those of my employer *
  38.  
  39.  
  40.